home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / misc-part1 / 571 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.4 KB
  1. Path: comma.rhein.de!serpens!not-for-mail
  2. From: mlelstv@serpens.rhein.de (Michael van Elst)
  3. Newsgroups: comp.sys.amiga.misc
  4. Subject: Re: OS features
  5. Date: 7 Jan 1996 18:47:03 +0100
  6. Organization: dis-
  7. Message-ID: <4cp0un$cve@serpens.rhein.de>
  8. References: <92747544038@PAPA.NORTH.DE> <4b3h9s$1st@alterdial.UU.NET> <2152.6561T63T2136@cycor.ca> <4b7i18$si1@vixen.cso.uiuc.edu> <oj6raxxrr0o.fsf@hpsrk.fc.hp.com> <13213431@sourcery.han.de>
  9. NNTP-Posting-Host: serpens.rhein.de
  10.  
  11. "Olaf Barthel" <olsen@sourcery.han.de> writes:
  12.  
  13. >problem to solve: how to implement shared memory accesses and interprocess
  14. >communication without running into the same trouble the original Amiga
  15. >shared memory space causes?
  16.  
  17. Protection is usually an asymmetric task. A (user)task must not corrupt data
  18. structures used by other (user)tasks but a system library that manages
  19. shared objects may corrupt data structures in (user)tasks. Reason is
  20. that a shared library can be debugged more easily.
  21.  
  22. For interprocess communication one has to provide a new protected method.
  23. Messages of non-trusted tasks may have to checked for consistency.
  24. Again, for most applications we have one "server" that is shared among
  25. several clients. The server can be made for error proof and thus is
  26. allowed to corrupt client data. But the client must not corrupt server
  27. data or the data of other clients.
  28.  
  29. Anyway, before you can think about memory protection you have to solve
  30. resource tracking. There are some difficulties involved, mainly in
  31. arbitration of shared objects (or rather the lack of arbitration).
  32.  
  33. >   That's an idea. I have seen similar under BeOS which can put contiguous
  34. >memory regions together from fragments.
  35.  
  36. With virtual memory the fragmentation exists in the virtual address
  37. space. The effect of this fragmentation is small because the virtual
  38. address space is much larger and because virtual addresses are allocated
  39. with a rather coarse granularity. Fragmentation smaller than the page
  40. size just affects one task and is effectively removed when the task
  41. ends.
  42. Separated address spaces for each process are even better because
  43. the total address space now grows with the number of processes. But
  44. this approach costs a lot in compatibility. It might be possible
  45. to use partially separated adress spaces though in new programs.
  46.  
  47. Regards,
  48. -- 
  49.                                 Michael van Elst
  50.  
  51. Internet: mlelstv@serpens.rhein.de
  52.                                 "A potential Snark may lurk in every tree."
  53.